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Abstract 


The BitTorrent file distribution system uses 

It 
achieves a higher level of robustness and resource uti- 
lization than any currently known cooperative tech- 
nique. We explain what BitTorrent does, and how 
economic methods are used to achieve that goal. 


1 What BitTorrent Does 


When a file is made available using HTTP, all upload 
cost is placed on the hosting machine. With BitTor- 


us making hosting a file with a potentially unlim- 
ited number of downloaders affordable. 

Researchers have attempted to find practical tech- 
niges to do this before[3]. It has not been previously 
deployed on a large scale because the logistical and 
robustness problems are quite difficult. Simply figur- 
ing out which peers have what parts of the file and 
where they should be sent is difficult to do without 
incurring a huge overhead. In addition, real deploy- 
ments experience very high churn rates. Peers rarely 
connect for more than a few hours, and frequently 
for only a few minutes [4]. Finally, there is a gen- 
eral problem of fairness [1]. The total download rate 
across all downloaders must, of mathematical neces- 
sity, be equal to the total upload rate. The strategy 
for allocating upload which seems most likely to make 
peers happy with their download rates is to make 


ease of use has contributed greatly to BitTorrent’s 
adoption, and 
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each peer’s download rate be proportional to their 
upload rate. In practice it’s very difficult to keep peer 
download rates from sometimes dropping to zero by 
chance, much less make upload and download rates 
be correlated. We will explain how BitTorrent solves 
all of these problems well. 


1.1 BitTorrent Interface 


BitTorrent’s 
ble. Users launch it by clicking on a hyperlink to the 


file they wish to download, and are given a standard 
“Save As” dialo 


This extreme 


which are described 


in this paper. 


1.2 Deployment 


The decision to use BitTorrent is made by the pub- 
lisher of a file. Downloaders use BitTorrent because 
it’s the only way to get the file they want. 


(meaning ones which do not have the 


whole file), helping peers find each other. 
Although trackers are the only way for peers to 
find each other, and the only point of coordination 


at all, 
Random graphs have very 


The peak of incom- good robustness properties [2]. Many peer selection 
plete downloaders passes as downloaders complete. algorithms result in a power law graph, which can 
The peak of incomplete downloaders passes as fin- get segmented after only a small amount of churn. 
ished downloaders stop uploading. Note that all connections between peers can transfer 
in both directions. 

In order to keep track of which peers have what, 


file made available by host, downloaders use BT 
because they want the file.downloaders upload while I 
downloading, then leave. 


2 Technical Framework Era- 
sure codes have been suggested as a technique which 
2.1 Publishing Content might help with file distribution [3], but this much 


simpler approach has proven to be workable. 


To start a BitTorrent deployment, a static file with 
the extension .torrent is put on an ordinary web They of course cannot download 


server. 


from peers they aren’t connected to, and sometimes 
peers don’t have any pieces they want or won’t cur- 
rently let them download. Strategies for peers dis- 
allowing downloading from them, known as chok- 
ing, will be discussed later. Other suggested ap- 
proaches to file distribution have generally involved 
a tree structure, which doesn’t utilize the upload ca- 
pacity of leaves. Simply having peers announce what 
they have results in less than a tenth of a percent 
bandwidth overhead and reliably utilizes all available 
upload capacity. 


They speak a very 
simple protocol layered on top of HTTP in which 
a downloader sends information about what file it’s 
downloading, what port it’s listening on, and similar 
information, and the tracker responds with a list of 
contact information for peers which are downloading 
the same file. Downloaders then use this information 
to connect to each other. 


The band- 
width requirements of the tracker and web server are 
very low, while the seed must send out at least one 
complete copy of the original file. 


2.3 Pipelining 


When transferring data like BitTorrent 
does, it is very important to 
to avoid a delay between 
pieces being sent, which is disastrous for transfer 


rates. BitTorrent facilitates this by 


2.2 Peer Distribution 


All logistical problems of file downloading are han- 
dled in the interactions between peers. Some infor- 
mation about upload and download rates is sent to 
the tracker, but that’s just for statistics gathering. The amount 
The tracker’s responsibilities are strictly limited to of data to pipeline has been selected as a value which 


2.4 Piece Selection 


Selecting pieces to download in a good order is very 
important for good performance. A poor piece se- 
lection algorithm can result in having all the pieces 
which are currently on offer or, on the flip side, not 
having any pieces to upload to peers you wish to. 


2.4.1 Strict Priority 


BitTorrent’s first policy for piece selection is that 


does a good job of getting complete pieces as quickly 
as possible. 


2.4.2 Rarest First 


When selecting which piece to start downloading 


next, 
a technique we 


refer to as ’rarest first’. This technique does a good 


job of 
so uploading can be done when 


wanted. It also makes sure that pieces which are 
more common are left for later, so the likelihood that 
a peer which currently is offering upload will later 
not have anything of interest is reduced. 

Information theory dictates that no downloaders 
can complete until every part of the file has been up- 
loaded by the seed. For deployments with a single 
seed whose upload capacity is considerably less than 
that of many downloaders, performance is much bet- 
ter if different downloaders get different pieces from 
the seed, since redundant downloads waste the op- 
portunity for the seed to get more information out. 
Rarest first does a good job of only downloading new 
pieces from the seed, since downloaders will be able 
to see that their other peers have pieces the seed has 
uploaded already. 

For some deployments the original seed is eventu- 
ally taken down for cost reasons, leaving only current 
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downloaders to upload. This leads to a very signifi- 
cant risk of a particular piece no longer being avail- 
able from any current downloaders. Rarest first again 
handles this well, by replicating the rarest pieces as 
quickly as possible thus reducing the risk of them get- 
ting completely lost as current peers stop uploading. 


2.4.3 Random First Piece 


An exception to rarest first is 
At that time, the peer has 


Rare pieces are generally only present 
on one peer, so they would be downloaded slower 
than pieces which are present on multiple peers for 
which it’s possible to download sub-pieces from dif- 
ferent places. For this reason, 


2.4.4 Endgame Mode 


Sometimes a piece will be requested from a peer with 
very slow transfer rates. This isn’t a problem in the 
middle of a download, but could potentially delay a 
download’s finish. To keep that from happening, 


In practice not much bandwidth is 
wasted this way, since the endgame period is very 
short, and the end of a file is always downloaded 
quickly. 


3 Choking Algorithms 


BitTorrent does no central resource allocation. 


To cooper- 
ate, peers upload, and to not cooperate they ’choke’ 
peers. It 
stops uploading, but downloading can still happen 


and the connection doesn’t need to be renegotiated 
when choking stops. 

The choking algorithm isn’t technically part of the 
BitTorrent wire protocol, but is necessary for good 
performance. A good choking algorithm should uti- 
lize all available resources, provide reasonably consis- 
tent download rates for everyone, and be somewhat 
resistant to peers only downloading and not upload- 
ing. 


3.1 Pareto Efficiency 


Well known economic theories show that systems 


tend to have all of the above properties. In 
computer science terms, seeking pareto efficiency is a 
local optimization algorithm in which pairs of coun- 
terparties see if they can improve their lot together, 
and such algorithms tend to lead to global optima. 
Specifically, 


BitTorrent’s choking algorithms attempt to achieve 


pareto efficiency using a more fleshed out version of 


tit-for-tat than that used to play prisoner’s dilemma. 


3.2 BitTorrent’s Choking Algorithm 


On a technical level, each BitTorrent peer 


approach allows TCP’s built-in congestion control to 
reliably saturate upload capacity. 

Decisions as to which peers to unchoke are 
‘strictly on current download rate, Calculating cur- 
rent download rate meaningfully is a surprisingly dif- 
ficult problem; The current implementation essen- 


tially uses a rolling 20-second average. Former chok- 


ing algorithms used information about long-term net 
transfer amounts, but that performed poorly because 
the value of bandwidth shifts rapidly over time as re- 
sources go away and become available. 

To avoid situations in which resources are wasted 
by rapidly choking and unchoking peers, 


and then leave the situation as is until 
the next ten second period is up. Ten seconds is a 
long enough period of time for TCP to ramp up new 
transfers to their full capacity. 


3.3 Optimistic Unchoking 


Simply uploading to the peers which provide the best 
download rate would suffer from having no method of 


To fix this, at all times 


Which peer is the optimistic unchoke is 
(30 seconds). 30 
seconds is enough time for the upload to get to full 


capacity, the download to reciprocate, and the down- 
load to get to full capacity. The analogy with tit- 
for-tat here is quite remarkable; 


3.4 Anti-snubbing 


Occasionally a BitTorrent peer will be choked by all 
peers which it was formerly downloading from. In 
such cases it will usually continue to get poor down- 
load rates until the optimistic unchoke finds better 
peers. To mitigate this problem, 


(an exception to 
the exactly one optimistic unchoke rule mentioned 
above), which causes download rates to recover much 
more quickly when they falter. 


3.5 Upload Only 


Once a peer is done downloading, it no longer has 
useful download rates to decide which peers to up- 
load to. The current implementation then 
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Figure 1: The number of complete downloaders 
(‘seeders’) and incomplete downloaders (‘leechers’) of 
a large deployment of an over 400 megabyte file over 
time. There must have been at least 1000 successful 
downloads, since at one time there were that many 
complete downloaders. The actual number of down- 
loads completed during this period was probably sev- 
eral times that. 


4 Real World Experience 


BitTorrent not only is already implemented, but is al- 
ready widely deployed. It routinely serves files hun- 
dreds of megabytes in size to hundreds of concur- 
rent downloaders. The largest known deployments 
have had over a thousand simultaneous downloaders. 
(which hasn’t actually 


been reached) 
Currently that’s about a thousandth 
the total amount of bandwidth used, and some minor 
protocol extensions will probably get it down to a ten 
thousandth. 
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